packages/query-core/src/types.ts (1)

1329-1333: Add brief JSDoc for the new CancelOptions.isObserverRemoval flag

Nice, the new flag threads intent through the cancel pipeline. Since CancelOptions is part of the public types, add a short JSDoc to clarify internal usage so consumers don’t rely on it.

 export interface CancelOptions {
   revert?: boolean
   silent?: boolean
+  /**
+   * Internal: marks cancellation caused by observer removal to disambiguate revert behavior.
+   * Not intended for external usage.
+   * @internal
+   */
   isObserverRemoval?: boolean
 }

packages/query-core/src/query.ts (1)

556-573: Avoid reverting to idle when a new active observer exists; refine the guard

The new guard prevents an async revert from overriding an in-flight fetch after a quick re-subscribe. This addresses the StrictMode remount issue.

To avoid edge cases where a disabled observer re-subscribes (enabled: false) and we still skip revert (leaving fetchStatus stuck at 'fetching' without an active fetch), consider checking for an active observer rather than just a non-empty list.

-          if (error.isObserverRemoval && this.observers.length > 0) {
+          if (error.isObserverRemoval && this.isActive()) {
             if (this.state.data === undefined) {
               throw error
             }
             return this.state.data
           }

Optionally, add a short comment explaining why revert is skipped to aid future maintainers.

packages/query-core/src/__tests__/query.test.tsx (1)

1195-1239: Remove ts-expect-error by typing the mock; clarify intent

The test relies on destructuring signal to mark the abortSignal as consumed. You can avoid the ts-expect-error by typing the mock to QueryFunction and keep the test self-documenting.

-    // @ts-expect-error This field has been added for troubleshooting purposes. Disable ts error for testing.
-    const queryFn = vi.fn(async ({ signal }) => {
+    const queryFn = vi.fn<QueryFunction<string, ReturnType<typeof queryKey>>>(async ({ signal }) => {
       await sleep(50)
       return 'data'
     })

Additionally, add the missing type import at the top of the file:

// augment existing import type block from '..'
import type {
  QueryCache,
  QueryFunctionContext,
  QueryFunction, // <- add this
  QueryKey,
  QueryObserverResult,
} from '..'

This keeps the test free of suppression comments and makes the "signal consumption" intent explicit.

If you'd like, I can also contribute a complementary test that covers the edge-case where a disabled observer re-subscribes to ensure we still revert correctly.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

packages/query-core/src/__tests__/query.test.tsx (2)

1196-1237: Great regression test; consider asserting the cancellation type and avoiding microtask timing flakiness

This test reliably reproduces the StrictMode remount race and validates the intended behavior. Two small improvements:

• Assert the first fetch rejects with CancelledError (parity with the second test).
• Replace the microtask flush with waitFor to avoid timing flakiness tied to async cancel scheduling.

Apply this diff:

-    await promise1.catch(() => {})
-
-    await Promise.resolve()
+    await expect(promise1).rejects.toBeInstanceOf(CancelledError)
+    await vi.waitFor(() =>
+      expect(query.state.fetchStatus).toBe('fetching'),
+    )

---

1199-1203: Minor: add a clarifying comment about signal destructuring

Destructuring signal intentionally consumes the AbortSignal getter to set #abortSignalConsumed = true. A short comment will make the intent obvious for future readers.

-    const queryFn = vi.fn(async ({ signal: _signal }) => {
+    const queryFn = vi.fn(async ({ signal: _signal }) => {
+      // Destructure `signal` to intentionally consume it so observer-removal uses revert-cancel path
       await sleep(50)
       return 'data'
     })

packages/query-core/src/query.ts (1)

556-573: Correctly avoid revert when cancellation stems from observer removal and observers are active

The guard if (error.isObserverRemoval && this.isActive()) is the key to preventing the premature flip to 'idle'. Behavior looks correct:

• With active observers, skip revert. If there’s no cached data, rethrow to let the caller handle cancellation. If cached data exists, resolve with it without altering fetchStatus, preserving the in-progress state for the next fetch.
• Otherwise, revert state and set fetchStatus: 'idle' (previous semantics).

Two notes:

• Using isActive() (instead of just observers.length > 0) is more precise: it avoids skipping revert when only disabled observers are present and no new fetch will start. Good call.
• Consider adding a brief comment explaining why we skip the revert here (to prevent the first fetch’s async cancellation from overriding the state after a new observer triggers a second fetch), for future maintainers.

Suggested inline comment:

-          if (error.isObserverRemoval && this.isActive()) {
+          // If cancellation was caused by observer removal and there are active observers again,
+          // do not revert to idle: a new fetch may already be in flight, and reverting would
+          // incorrectly flip isLoading/isFetching to false under StrictMode remounts.
+          if (error.isObserverRemoval && this.isActive()) {

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.